The Unsorted BBS Collection/thegreatunsorted.tar/thegreatunsorted/texts/boxes/Operator Service Position System.txt

Text File | 1994-02-13 | 12KB | 217 lines

The LOD Technical Journal: File #6 of 12

                Operator Service Position System
                            (OSPS)
                        By The Enforcer

Introduction
-*-*-*-*-*-*

OSPS is a replacement for the Traffic Service Position System (TSPS). For a
description of the TSPS console see The Marauder's article in the LOD
Technical Journal Number One, File Four. The main difference between the two
is that OSPS can be integrated with the 5ESS Switch itself whereas TSPS was
only stand alone. OSPS uses the full capabilites of 5ESS and ISDN to provide
more services. OSPS also allows for a high degree of automation and by using
standard 5ESS configurations, maint. is simplified.

Remote Capabilites
-*-*-*-*-*-*-*-*-*

By using 5ESS, OSPS takes advantage of its remote capabilites. OSPS can be
used to perform any traditional operator functions and just 1 OSPS switch can
handle up to 128 operator teams. This enables operators to be located at one
centralized location where thousands of operators work. (To picture this,
remember that MCI commercial with all the operators in that giant room) Huge
operator centres can be located at great distances from their host areas.
Conceivably, one huge OSPS centre could serve the entire nation. OSPS can
either be made a component of a 5ESS Switch and handle various services or a
single switch dealing with only toll or local calls. Control can be
transferred from one OSPS to another. If there is low demand, a system crash
or other emergency control can be passed on to another secure OSPS. This
process is called interflow. One usage is during off-peak hours, when usage
goes down for an OSPS centre to close down, and switch everything to another
center. OSPS can use any number of signalling systems, with different
languages or country specific requirements.

Architecture
-*-*-*-*-*-*

Operator terminals communicate with switches using ISDN paths. This is done
by connecting to positioning switch modules (PSMs). PSMs are simply the
switching modules (SMs) found on 5ESS. There are numerous other SMs that use
analog and digital trunks to perform a variety of services. SMs can be
installed remotely in which case they are remote switching modules (RSMs) or
optically remote switching modules (ORMs).

Operator terminals allow operators to regulate calls and transfer data on a
ISDN. Basic rate interface (BRI) is an integrated services line unit (ISLU)
that connects up to the PSM.

There are four main operator terminals - video display terminal (VDT) for
toll assistance, basic services terminal (BST) for listing services, combined
services terminal (CST) for both of these functions and intelligent
communication workstation (ICW) for International traffic assistance. Knowing
these terminals can come in handy when you are dealing with an operator, if
you can't get an answer ask to know which terminal they are looking at.

OSPS is automated as much as possible. Digital service units (DSUs) on the
SMs provide digital automations when required such as requesting you to
insert more red box tones (uh, coins) to continue your call.

The architecture behind OSPS is based on the call processing architecture of
5ESS, and simply copies many of its functions. To originate and terminate
OSPS the originating terminal process (OTP) and terminating terminal process
(TTP) are used. The OTP is started when a trunk is seized, usually in the
initiation of a toll call, and decides where to place the calls such as to
automated billing etc. OTP also monitors the calls as its in progress and
conducts billing. Should OTP move the call to an operator, it will label it
as one of 128 possible conditions based on the dialled number and trunk
group. TTP is started when the call goes out from the switch on outgoing
trunks to enable signalling.

Automatic Call Distribution (ACD)
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

ACD controls incoming calls to operator teams, placing them in queues if
needed and directs the call depending on its condition to the right operator.
At the OSPS centre, there are 128 teams, 1 for each condition. If there are
no available operators ACD will place the call in one for four queue
conditions. The first is ringing, the next two are announcements and the
fourth is an announcement followed by a hanging-up of the caller. The ACD
constantly has the status for every operator. The three conditions are made
busy, busy and available. Made busy is an otherwise available operator that
isn't ready to receive calls. If an operator team services more than one call
type, and if one call type is queued the call with the highest "delay ratio"
(the expected wait time) will get the next available operator. Supporting
teams, up to 8 of which back up the principle teams act as a "reserve" if the
principle ones are busy. Subject to the condition that a queue is backed up
higher than the "outflow threshold" and the supporting team doesn't have a
queue past the threshold either. The position terminal process (PTP) logs
operator status by looking at operator inputs, calls, etc. PTP will then
route the call to the operator, place it in a queue or route it to another
operator.

PTP
-*-

PTP has four models:

virtual terminal (VT) - Takes keystroke inputs, checks them to see if they
are legal commands and passes them on.

feature model (FM) - Handles the status of the operator, if an operator logs
in, it will indicate that the operator is now available.

near model (NM) - Processes the operator inputs.

call coordination model (CC) - Handles coordination between PTP and other
operations. For example signalling between PTP and OTP/TTP.

Here is how AT&T describes a typical event:

. A seizure is detected on an incoming trunk, and an OTP is created.
. Signalling information, such as dialled digits and the back number, is
collected and analyzed; the need for an operator is recognized.
. Call type is determined from the dialled digits and incoming trunk group to
classify this as an OSPS call of type 1. The ACD administrator has assigned
type 1 calls with serving team A as the principal team and serving team B as
the supporting team.
. The OTP sends a message to the ACD requesting an operator. This message
identified the call as type 1 and obtains other call information.
. The ACD determines that calls of type 1 are being queued.
. The call is queued, and the expected delay is calculated. By comparing the
expected delay with administratively specified delay thresholds, the ACD
determines whether a delay announcement should be provided to the caller. .
A message is sent to the OTP with this information.
. The OTP first connects the delay announcement, then provides audible ring
to the caller.
. At this point, an operator from serving team B becomes available, and the
call of interest has migrated to the head of call type 1 queue. The ACD
determines that no calls are waiting in any of the principal queues for team
B, and further determines that the next call in the call type 1 queue is
eligible to be intraflowed to team B. The ACD informs the OTP to send the
call to the available operator from team B by sending a message to the PTP in
the PSM. It then marks that position as busy with a call.
. The PTP, via the CC model, establishes the voice path between the caller
and the operator and sends appropriate display messages to the operator
terminal, via the VT model, to provide the initial call seizure information.
. The customer requests a collect call from the operator who depresses the
collect key and enters the number to be called. Messages are sent from the
operator terminal to the PTP to relay the information. The VT model processes
each incoming message and forwards the message to the near model. The near
model marks the call as collect and initiates the connection to the forward
party via a new CC model. This results in creation of a TTP and appropriate
interswitch signalling to ring the forward party.
. After the forward party answers, the operator secures agreement for the
collect billing and releases the call from the position via the position
release key. This keystroke is first processed by VT and passed on to the
near model. The PTP notifies the OTP of the collect billing arrangements. The
talking paths are reconfigured to eliminate the operator position. The two
parties on the call are now speaking directly without an operator on the
call.
. The operator terminal screen is cleared by VT. The FM reports its status
back to the ACD as available to handle another call.
. At the conclusion of the call, a billing record is made by the OTP.

Automation and Efficiency
-*-*-*-*-*-*-*-*-*-*-*-*-

OSPS is designed to be as automated as is possible. It is supposed to make as
little use of human operators as can be gotten away with. When you think
about it that's the result of OSPS - human operators are becoming less and
less needed. If it wouldn't be for all the potential uproar, they'd get rid
of all human operators entirely. They are regarded as a horribly expensive
way to handle calls. OSPS allows operators comfy little terminals and pulls
them out of situations where they are needed as soon as they aren't required.
For example after obtaining a number for collect billing, the rest of the
process - voice acceptance can be automated.

Many services in the past that were separate are now combined under OSPS. For
example toll and directory assistance operators had to be kept available in
large numbers to handle call surges. Meaning toll assistance can be queued
up, while directory assistance has available operators. Now with CST, an
operator can handle both services.


Data Communications
-*-*-*-*-*-*-*-*-*-

ISDN is used to transfer data in OSPS. External systems can also be reached
for such purposes as directory assistance information. Three layers are
involved in OSPS operator-switch exchanges:

layer 1 - the physical layer - Gives synchronous data transmission from the
terminal to the ISLU.

layer 2 - the link layer - Provides point-to-point exchanges between the
terminal and PSM.

layer 3 - the packet layer - Is the layer 3 protocol of X.25. It's a resident
virtual circuit for exchanges between the terminals and the SM's processor.
Which can be used in switch virtual circuit connections to external
databases.

Databases
-*-*-*-*-

OSPS uses databases during most calls. To do such functions as check the
validity of calling card accounts to prevent cancelled cards from being used.
Millions of database queries take place every 24 hours. Because of the
immense size of these databases, they can't all fit in 5ESS. So external
databases are used.

Common channel interoffice signalling (CCIS) links OSPS with external data.
To link with external computers CC7 is used. Data is returned to OSPS from
nodes on CCS such as the line info database (LIDB) or billing validation
application (BVA). These two nodes handles your Bell's validation of all
collect, third number and calling cards.

The X.25 protocol is also used to connect OSPS with other databases. Each
database has an ISDN directory number. So one can scan out the addresses and
access them on the public PSNs. Since your RBOC doesn't want people messing
around with their BILLING databases, they are put in a closed user group
(CUG).
---------------------------------------------------------------------------